• Replace unsafe json_encode with WordPress wp_json_encode in inline script tags
• Hardens JSON output security for TinyMCE editor and frontend table rendering
• Prevents potential script-breaking payloads in HTML script contexts

Secure TinyMCE table payload JSON encoding

• Replaced json_encode($tables) with wp_json_encode($tables) in TinyMCE editor footer script
• Secures JSON output for table data injected into inline script context

app/Hooks/Handlers/EditorBlockHandler.php

Secure inline JavaScript JSON encoding for tables

• Replaced json_encode($cartItems) with wp_json_encode($cartItems) in WooCommerce cart footer
 script
• Replaced json_encode($vars, true) with wp_json_encode($vars) in table instance variables
 footer script
• Removes unnecessary second parameter from wp_json_encode call

app/Modules/DataProviders/NinjaFooTable.php

Description

NinjaFooTable::addInlineVars now emits wp_json_encode($vars) with default options, removing the
previously-passed non-zero json_encode options value (true), which can change how characters like
'<' are represented in the inline <script> payload. Because $vars includes user-controlled values
(e.g., post title/caption) and is consumed directly by frontend JS from window[instance], a payload
containing '</script>' can terminate the script early and break initialization and/or enable script
injection.

Code

app/Modules/DataProviders/NinjaFooTable.php[771]

+                window['<?php echo esc_attr($table_instance_name);?>'] = <?php echo wp_json_encode($vars); ?>

Evidence

The table config object is printed directly into an inline script tag (no additional escaping
layer), and it includes user-controlled fields (title, caption) plus can be modified by a filter;
frontend JS reads that global and uses it to initialize tables. If the JSON encoder outputs literal
'<' sequences for those values (e.g., in a '</script>' substring), the HTML parser will end the
script tag before the assignment completes, breaking the global config and the subsequent table
initialization path.

app/Modules/DataProviders/NinjaFooTable.php[500-516]
app/Modules/DataProviders/NinjaFooTable.php[766-775]
resources/public/js/_tableApp.js[48-59]
boot/ninja-tables-global-function.php[1137-1140]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`addInlineVars()` prints a JSON object directly into an inline `<script>` assignment. The PR switched `json_encode($vars, true)` to `wp_json_encode($vars)` but dropped the previously supplied non-zero options value, which can change how characters (notably `<` as part of `</script>`) are emitted, risking early script termination and breaking table initialization.

### Issue Context
- `$vars` includes user-controlled data (e.g., `$table->post_title`, caption meta) and is also mutable via the `ninja_table_rendering_table_vars` filter.
- Frontend JS reads `window[table_instance_name]` and initializes the table from it.

### Fix Focus Areas
- app/Modules/DataProviders/NinjaFooTable.php[766-775]
- app/Modules/DataProviders/NinjaFooTable.php[500-516]
- resources/public/js/_tableApp.js[48-59]

### Implementation sketch
- Change `wp_json_encode($vars)` to `wp_json_encode($vars, JSON_HEX_TAG | JSON_HEX_AMP | JSON_HEX_APOS | JSON_HEX_QUOT)` (or at minimum ensure the option that prevents literal `<` in output is enabled), and consider adding a trailing `;` after the assignment.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

• app/Hooks/Handlers/EditorBlockHandler.php - No issues
• app/Modules/DataProviders/NinjaFooTable.php - No issues